Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

block: Keep RTMIN through RTMAX signals blocked in child #454

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

nfraprado
Copy link

@nfraprado nfraprado commented Oct 17, 2021

When a child process is forked for a block, it has the signals RTMIN
through RTMAX blocked by default, but block_child_sig() unblocks all
signals including these.

Unblocking these signals is troublesome given that:

  • The easiest way to signal i3blocks for an update is through pkill (as
    shown at https://vivien.github.io/i3blocks/#_signal ). But pkill sends
    a signal to all processes with that name, which includes the child
    fork.
  • Since those signals are unblocked, but not handled, in the child, when
    one of them is sent to i3blocks, and while it is being handled in
    the child process, another one is sent, the child process will also
    receive the signal and therefore crash since it is unhandled.

If we assume that the RTMIN through RTMAX signals are uncommon enough
that they won't be used in the child process, the solution is as easy as
keeping these signals blocked for the child process.

Fixes #455.

When a child process is forked for a block, it has the signals RTMIN
through RTMAX blocked by default, but block_child_sig() unblocks all
signals including these.

Unblocking these signals is troublesome given that:
- The easiest way to signal i3blocks for an update is through pkill (as
  shown at https://vivien.github.io/i3blocks/#_signal ). But pkill sends
  a signal to all processes with that name, which includes the child
  fork.
- Since those signals are unblocked, but not handled, in the child, when
  one of them is sent to i3blocks, and while it is being handled in
  the child process, another one is sent, the child process will also
  receive the signal and therefore crash since it is unhandled.

If we assume that the RTMIN through RTMAX signals are uncommon enough
that they won't be used in the child process, the solution is as easy as
keeping these signals blocked for the child process.
vivien added a commit that referenced this pull request Jan 13, 2023
Now that the original signal mask from the parent process is stored
in bar->sigset, use it to restore the signal set in child processes
instead of unblocking them all.

Refs #454
Closes #455
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Two consecutive signals crash block until next timeout
1 participant